OLE Edit is an OLE server capable of editing text files for other
applications.
In use, when a file is sent to it, OLE Edit opens up a window allowing
editing operations. Other than available memory there is no practical limit
on the number of sessions OLE Edit can handle. The file is sent back to the
client when OK is clicked, and as normal, clicking with Adjust retains the
window on screen. Even if it is closed, however, the file is still retained
by OLE Edit in order that future edit requests by the client (format 2 on
Message_OLEOpenSession) can be dealt with much faster.
OLE Edit will discard a file only when Cancel is clicked, or when told to by
its client or when quit from the Task Manager. When quit it will inform all
clients that their sessions are being closed. When OLE Edit is told to close
its one remaining session, it will quit automatically. Therefore if a client
sends a close-all-sessions when it is quit, and OLE Edit has no sessions with
another client, OLE will quit along with its client.
There is no iconbar icon, as this application only exists to serve others and
is not useful in its own right.
OLE Edit version 2.00 is a much more powerful editor than OLEdit was. It has
been completely re-written using RiscOSLib, which makes certain other things
a right royal pain (pane handling is flaky, for instance, and proper
titlebar/close-icon control is near-impossible) but which does have a full
text editor. So now OLE Edit gives you something extremely similar to !Edit.
As such it need not really be considered a mere 'stop-gap' any more as it is
now a powerful and fully-featured text editor and (while improvements may be
forthcoming from this quarter) will now suffice until !Edit in a future RISC
OS is OLE compliant. In other words, probably forever! Being programmed using
RiscOSLib, it *may* be compatible with RISC OS 2, but I have no way of
testing this.
OLE Edit may be distributed freely with freeware and commercial applications
which need to OLE text files, so such applications can rest secure in the
knowledge that there is an OLE text server available on its run-time system.
Behaviour
~~~~~~~~~
OLE Edit conforms to Computer Concepts' OLE protocol as defined in the file
OLESpec, included here. Note that there is an error in this file (apart from
the typos) under Message_OLECloseSession, where the paragraph under the
message block description *should* read:
Note, the server can send this message to a client or broadcast it to
all clients when sessions are being closed from the server's end. (ie
the user is closing the application down or removing one of its
documents).
The original said that 'the *client* can send this message to a client or
broadcast it to all clients when sessions are being closed from the clients
end.', which was nonsensical and confused me for a while as it seemed there
was no way for a server to tell a client when it's dying. Well, there is. The
server can send the Message_OLECloseSession as well as receive it. In fact
the notes in OLESpec regarding Message_OLECloseSession are still ambiguous on
what should happen when you send -1 as a session number. I've tried to be
intelligent, so that if OLE Edit receives such a message from a client it
only closes down the sessions belonging to the task which sent it, not all of
them (of course, that may *be* all of them, in which case OLE Edit will quit
itself). Conversely, it seems that clients receiving such a message from a
server should only close down editing sessions it has with that server. This
then ensures that certain servers or clients dying don't interfere with other
servers and clients which probably use different filetypes and are an
unrelated operation.
The !Boot file is set up so that OLE Edit will only announce itself as an OLE
server for text files if there is not one already present.
Further ruminations on OLE
~~~~~~~~~~~~~~~~~~~~~~~~~~
I note the comments made on Arcade re: the thought that OLE is something of a
misnomer for what this, and the CC OLE Protocol provide, which is not in the
same league as OLE as found on other platforms.
Here's a hint when writing a server that may want to use this: Assuming your
file is not too big, why not send it via PipeFS rather than Wimp$Scrap? Even
the old OLEdit 1.00 could cope with this as it's invisible from the server's
end. This means that the file is transferred via RAM instead of disk, thus
making it *much* faster, and far more convenient for floppy-users. When you
send your file, save it to "Pipe:$.<leafname>". According to the protocol,
the server *can* send back a different pathname with the OLEFileChanged
message in case it decided that the file grew big enough for PipeFS not to be
appropriate, and so the client should take note of this and not blindly
assume it was put back where it came from. At present, however, OLE Edit will
not change the pathname; it will *always* put the file back where it came
from, regardless of how much it may have grown and where it might have been
Saved in the meantime.
There is one fly in this ointment however, in that CC's OLE Support module
does not like PipeFS. It sends the file all right, but won't send back the
OLEFileChanged message when the file is saved back. Presumably this is
because the file-watching facility stops when the file disappears from
Pipe:$, which it does as soon as the server reads it in. That's the way
PipeFS seems to work. So if you determine that the OLE server for your new
session is in fact OLE Support (scan the OLEServer$Type system variable), go
via Wimp$Scrap or some other 'real' filing system.
OLE Edit now only responds to requests to edit Text files. Beforehand it would intercept anything, once it was running, regardless of type. However, of course, a text editor might be wanted to edit files which are not Textfiles, eg Obey files, Desktop files, bare data files. Therefore my interpretation of how this is dealt with is as follows:
When you send the OLEOpenSession (formats 0 & 1), send in the filetype field
the type you want the file edited as. eg: an Obey file needs to be edited as
a text file. However, when you do your file save, set the filetype on the
saved file to the proper type (ie: Obey) OLE Edit will then edit the file as
a text file, ignoring files sent with a different type, but will still show
(in file info, save etc) that it is whatever type it was saved with.
